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[57] ABSTRACT 

An automated procurement system, in which a buyer 
workstation is in communication with a mainframe 
database that stores global data relevant to procurement 
documents and reports. The workstation is pro- 
grammed with an interactive buyer interface that dis- 
plays procurement documents, provides support data to 
aid in decision-making, and provides various document 
attachments. Data is uploaded and downloaded to and 
from the mainframe and the workstation in a manner 
that is transparent to the buyer. 
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curement, which include information that is already 

AUTOMATED PROCUREMENT SYSTEM WITH supplied as well as queries for data to be filled in by a 
MULTI-SYSTEM DATA ACCESS buyer. The buyer selects a particular document to be 

, processed, and either the workstation or the buyer de- 

TECHNICAL FIELD OF THE INVENTION 5 Lnines what support data is needed for processing the 
This invention relates to data processing computer selected document If the data is in the global data base, 
systems, and more particularly to a computerized pro- transfer software retrieves the data from the global 
curement system, which links multiple computer envi- database. Other programming displays the data at the 
ronments and which includes a buyer workstation that workstation, receives data input from the buyer, and 
displays various procurement documents and accesses 10 routes the document to other personnel involved in the 
system-wide data. procurement process. Regardless of whether the global 

BACKGROUND OF THE INVENTION ^ fe su PP Ued automatically or is requested by the 

buyer, the fact that its source is the mainframe rather 
In any business, the procurement of products and than the workstation is transparent to the buyer, 
services is likely to be a complicated process. Existing 15 A technical advantage of the invention is that paper 
procurement methods mvolve handling a variety of flow ra ^ procurement process is greatly reduced The 
documents, such as requests for purchase, purchase mvention routes electronic documents to appropriate 

^h£^ S "?? persons during the procurement process. Based oTinput 

These documents are printed and mailed or hand-deliv- u^ noc J «~JL*„™ ™a u „ -r 

ered to various personnel types, such as managers, buy- 20 business procedures, and data base mformaUon, 
ers, and suppKersS peSel type makesSropri- J^r^^* ^ ~* 
ate decisions, some based on information thatTdiffer- w ^ rk f tatl0n ™* determines the correct path upon 
ent than that used by other personnel types and some whlch to route documents. The mvention simulates the 
that are based on information that is global to more than paper t ™ h of Procurement, including attach- 

one personnel type. Each personnel type uses or adds 25 ments, approvals, and retention requirements, 
data contained in the procurement documents. During BRIEF DESCRIPTION OF THE DRAWINGS 
the process, a variety of retainment, copy, and attach- 
ment requirements apply to the different documents. FIG. 1 is a block diagram illustrating the various 

A need exists for an automated procurement system computer systems in communication with a mainframe, 
that reduces paper and provides electronic routing of 30 each used as part of a procurement process, 
appropriate information to all who are involved in the FIG. 2 illustrates the user interface of the workstation 
process. Ideally, the system should provide the informa- of FIG. 1, in particular, a buyer statistics window, 
tion as needed by each person, with as little intervention FIG. 3 illustrates the user interface of the workstation 
by these users as possible. of FIG. 1, in particular, a work list menu. 

One difficulty of providing such a system is related to 35 FIG. 4 illustrates the user interface of the workstation 
the difficulty of transferring data among different com- of FIG. 1, in particular, a RP work list window, 
puter systems. Existing computer systems are often FIG. 5 illustrates the user interface of the workstation 
categorized into three primary groups: mainframes, of FIG. 1, in particular, a RP work list sort menu, 
minicomputers, and microcomputers. Each of these FIG. 6 illustrates the user interface of the workstation 
groups uses different operating systems and different 40 of FIG. 1, in particular, an opened RP document 
data formats. Although significant advances have been FIG. 7 illustrates the user interface of the workstation 
made m networks that link computers that are designed of na h m particular, an RP attachments menu, 
for compaubihty. not aU computer systems are easily Ha 8A mustrates the user interface of the worksta- 
^^ZS^SS^ ^ one type of tion of FIG. t in particular, a delivery schedule attach- 

aJl ~r«T tt ... a j ment window. 

Another difficulty m providing an automated pro- nG 8B fflustrates ^ ^ mtcrface oftne worksta . 
clement system is overcoming longstanding trad,- don of Ra ^ m a q ZTm^^t^ 

Uonal methods of handling and routing documents. The dow ^ 4 auacumcm win 

system must provide an interface to the buyer that is ™U a .„ . , - r . - . 

easy to use, yet fulfills the demands of what can become 50 ™ 9 ****** the usermterfaceof the workstation 
a complex pattern of back and forth paper trails. In data ™ P"*^ * supportdata menu, 

processing involving the manipulation of large amounts . FI ^ J r ° "^t^tes the user interface of the worksta- 
of data, mainframe computer systems have traditionally toon ofFIG - X > m Particular, a sourcing search window, 
been used. However, most advances in interactive data mG 11 lllast rates the user interface of the worksta- 
entry and decision-making have been in connection 55 tion ofFIGl X * m particular, a commodity search win- 
with smaller computer systems, often microcomputer dow. 

or rninicomputer-based and referred to as workstations. FIGS. 12A and 12B illustrate the user interface of the 
An object of the invention is to combine the advan- workstation of FIG. 1, in particular, action menus for a 
tages of database capacity using mainframe computers ^ work list and an opened RP, respectively, 
and the advantages of user-interfacing using worksta- 60 FIG. 13 illustrates the user interface of the worksta- 
tions, for automating the procurement process. tion of FIG. 1, in particular, a PO work list specification 

menu. 

SUMMARY OF THE INVENTION nG . 14 mus ^ tes ^ ^ faterfilce of ^ worksta . 

One aspect of the invention is an automated procure- tion of FIG. 1, in particular, a PO work list window, 
ment method, using an interactive workstation having a 65 FIG. 15 illustrates the user interface of the worksta- 
local database and a buyer interface, in communication tion of FIG. 1, in particular, a PO work list sort menu, 
with a mainframe having a global database. The local FIG. 16 illustrates the user interface of the worksta- 
workstation displays various documents used for pro- tion of FIG. 1, in particular, a opened PO window. 
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FIG. 17 illustrates the user interface of the worksta- that it serves both the workstations 20 and mainframe 
tion of FIG. 1, in particular, a PO attachments menu. 11. Also, the invention is not limited to local area net- 

FIGS. 18A and 18B illustrate the user interface of the works, and the functions of server 19 and workstation 
workstation of FIG. 1, in particular, action menus for a 20 may be combined in a single computer unit In this 
PO work list and an opened PO, respectively. 5 situation, the transfer software runs in the background 

FIG. 19 illustrates the structure of the programming while the buyer interacts with the application software 
for one of the workstations of FIG. 1. in the foreground. 

FIG. 20 illustrates the interactive data transfer pro- Mainframe system 11 includes at least one database, 
cess of a buyer system. which stores global data to be accessed by one or more 

FIG. 21 illustrates the batch data transfer process of a 10 of the user systems. An example of mainframe system 11 
buyer station. is a mainframe computer system manufactured by IBM 

FIG. 22 illustrates the data transfer process of a main- Corporation, using the MVS operating system and an 
frame for both interactive and batch data transfers. Information Management System (IMS) teleprocessing 

DETAILED DESCRIPTION OF THE monitor for interactive access via terminals. Although 

INVENTION 15 tne following description is in terms of a single main- 

„ .„ . , ■ , frame system 11, more than one mainframe computer 

FIG. 1 illustrates a procurement system, with winch may be in communication with each other as mainframe 
the invention is designed to be useo\ Several user sys- n p rovided ^ ^ downloading and uploading in- 
terns are each in communication with a mainframe sys- chldes a means for identifying them, 
tern 11 The user systems include buyer system 10, 20 ^ ^ ^ other ^ b ^ 10 ^ ^ 

requmtoner system 12, supplier system 14, and man- LAN systems, stand-alone workstations, or mainframe 
ager system 13. As explained below, each user system A configuration * a m ^m, system 

may include standard computing equipment, such as a ^ £ 

processing unit, communications interface, display . , ™^ ^ wiuui upaow www » 

screen, printer, and memory. 25 termmals 0r M JS** 1 ^ apphC f U T 

As explained below, the operating systems and appli- pro^ammmg. Although tte following paragraphs de- 
cations programs of these user systems are not necessar- f nbe ^systems other than buyer system 10 m 
ily compatible. In fact, an advantage of the invention is of ^g^rations, the fonctionahty of 

that it provides access to global data that each of these ^ systems « * acconmhshed with different 
systems may generate or use. Although examples of 30 COn f^ tl0nS ^ * e concepts of me mventlon de " 
operating systems and applications for each system are sc ? be ? ™ e same ' 

described, these could be varied, with general concepts embodmient of ^ description, requisitioner 

of the invention remaining the same. system 12 and manager system 13 are mainframe sys- 

Buyer system 10 is a system of buyer workstations 20, tems ' for ^P 1 ^ mainframes using the IMS telepro- 
m communication with each other by means of a server 35 cessm £ monitor. The apphcations programs for these 

19. A user of a workstation 20 is referred to herein as a niainframes use relational databases, such as Database 2 
buyer. In the preferred embodiment, each buyer station (PB2X manufactured by IBM Corporation. Example of 
20 is a micro-computer, using an operating system a requisitioner system 12 and manager system 13 are the 
known as OS/2. Various terms associated with OS/2 EZ RE Q system and the Electronic Routing and Ap- 
are used throughout this description, and are known to 40 P 1 " 0 ^ (ERA) system, both manufactured by Texas 
those famili ar with OS/2. Instruments, Inc. 

The applications programs used with buyer station 10 Supplier system 14 is a mainframe and IMS system 
include a database manager, which is a relational data- m & uses DL/I database application programs. An ex- 
base. Other applications programming includes buyer ample of a sup plier s ystem is the TT Information Ex- 
interface software, which is described below in connec- 45 change System CITIES), manufactured by Texas Instru- 
tion with FIGS. 2-19. rnents, Inc. The mainframe links with DOS worksta- 

Server 19 provides data distribution to each worksta- tions having databases, such as Btrieve, manufactured 
tion 20. Some of this data, which is common to all users by Softcraft, Inc. 

of all workstations 20 is stored on server 19 and shared Buyer Workstation Interface 

by all workstations 20. Other data may be stored at a 50 . 

workstation 20. Both types of data are referred to herein The user interface of each buyer workstation 20 is 
as "local data'*, as opposed to "global data** stored in designed to handle a large volume and variety of data, 
mainframe 11. A number of display panels are used to display and 

An important aspect of the invention is a method of process this data. This visual presentation is modeled 
transferring data between buyer system 10 and main- 55 after a design approach known as multiple document 
frame system 11. The process of transferring data to interface, which includes a set of design rules for pres- 
buyer system 10 from mainframe system 11 is referred enting multiple documents or different views of the 
to herein as "downloading'*, whereas the process of same data in a consistent manner. A method of imple- 
transferring data from buyer workstation 10 to main- menting a multiple document interface is the use of 
frame system 11 is referred to as "uploading*'. The pro- 60 child display windows that operate under a top level 
gramming of workstation 20 and server 19 program- parent window. 

ming that implement these processes are described in In the preferred embodiment, the user interface is 
further detail below in connection with FIGS. 19 and implemented with the Presentation Manager shell, 

20. which is a well known companion to the OS/2 operat- 
ic a typical procurement system, a number of buyer 65 ing system. This permits the use of multiple display 

stations 20 are linked in a local area network (LAN), windows, A main menu process acts as the parent win- 
served by server 19. As will be explained below, how- dow for all buyer applications and manages their win- 
ever, server 19 is different from typical LAN servers in dows. 
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Consistent with the above design approach, each 
workstation 20 provides the buyer with appropriate 
documents for use during the procurement process. 
These documents are presented on a display screen as 
windows, with data fields to be considered by or to be 5 
filled in by the buyer, in a manner analogous to the data 
on forms and reports used in traditional non-automated 
procurement methods. Furthermore, each workstation 
20 routes these documents to and from the various user 
systems as needed, with appropriate copies and attach- 10 
ments. 

To provide these documents in an orderly manner, 
the application software for each workstation 20 in- 
cludes processes for providing the buyer with docu- 
ments, such as requests for purchase (RFs) and pur- 15 
chase orders (FO's). It displays these documents in 
display windows, and the buyer selects actions from 
command bars and menus. Buyer input is by means of a 
keyboard or mouse, or a combination of both. As will 
be evident from FIGS. 2-19, the invention is designed 20 
so that buyer input is facilitated with pick and choose 
selections via a mouse. 

FIG. 2 illustrates a buyer statistics window 21, which 
informs the buyer of RFs and PO's assigned to the 
buyer's workstation 20. This window is obtained by 25 
means of the Admin command on the command line 22. 
The programming of workstation 20 automatically up- 
dates the data in this window 21. 

FIG. 3 illustrates a work list menu 31, which is ob- 
tained by means of a Work List command on command 30 
line 22. As shown, various types of work lists may be 
obtained, including those listing RFs and PO's, as well 
as other types of documents. The particular work lists 
displayed on a workstation 20 contain documents as- 
signed to the workstation 20. The reverse video 32 is a 35 
standard menu selection means. 

As an example of work lists, communications be- 
tween requisition system 12 and buyer system 10 permit 
a workstation 20 to inform a buyer that RFs require 
processing. In a typical procurement system, RFs are 40 
sent to a manager fox approval, a step that the invention 
implements with manager system 13. Then, communi- 
cations and application programming causes a list of 
RFs to be presented to the buyer on the display of 
workstation 20. Thus, a RP work list contains all RFs 45 
assigned to a workstation 20. The programming auto- 
matically updates the work list contents as new RFs are 
added and old RFs become PO's. Other work lists may 
list other procurement documents, such as PO's and 
requests for return, for which processing is to be done, so 

FIG. 4 illustrates an RP work list 41 obtained by 
selecting an appropriate command from the menu of 
FIG. 3. The work list represents each RP in a com- 
pressed form, having a single line of the most pertinent 
data contained in the RFs. 55 

FIG. 5 illustrates a work list sort menu 51, which 
permits work lists to be sorted by various data fields. 
Referring again to FIG. 4, work list 41 is sorted in RP 
number sequence. However, using menu 51, selection 
criteria other than RP number may be used. Menu 51 60 
may also be used to change the worklist data fields 
displayed in work list 41. 

FIG. 6 illustrates an RP that has been opened, so that 
additional information is displayed. This opened RP 61 
represents the data that would be contained on a hard 65 
copy RP in a non-automated system. The data fields 
include such items as part number, description, com- 
modity code, supplier, and shipping destination. Some 
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data is supplied by other user systems, such an RP num- 
ber or a suggested supplier from requisition system 12, 
or comments and price approvals from manager system 
13. Additional data fields may be included by scrolling 
the window. Some of the data fields are protected, for 
buyer viewing only. Other data fields are unprotected 
for receiving buyer input 

FIG. 7 illustrates a document attachment menu 71, 
which permits attachments to be viewed, created, or 
updated on a workstation 20. These attachments include 
comments for keeping notes, special schedules, sub- 
items, special clauses, quotes, routing, and other supple- 
mental attachments that simulate those used in a non- 
automated procurement process. Attachment menu 71 
is a submenu of an opened RP window 61. 

FIG. 8A illustrates one of the attachments available 
using the menu of FIG. 7, a delivery schedule window 
81. Use of the Actions command 82 permits the buyer to 
add or modify data fields in this window. FIG. 8B illus- 
trates a second attachment available using the menu of 
FIG. 7. This attachment permits a buyer to send and 
receive quotes. The returned quotes are one of several 
decision aids provided by the user interface. 

When the buyer selects a particular document for 
processing, the programming of workstation 20 has 
previously determined what support information the 
buyer will most likely be using when the documents 
were downloaded. This decision is based on selected 
parameters, such as the buyer's division and purchasing 
history. The data is copied to a database on workstation 
20 or accessible to it via server 19, such that it becomes 
local data. However, as explained below, the program- 
ming also permits the workstation to receive non-local 
data during document processing, either automatically 
or in response to buyer actions. 

FIG. 9 illustrates a support data menu 91, which 
enables each workstation 20 to provide the buyer with 
supplemental data to help make purchasing decisions. 
Support information software is used to provide the 
buyer with administrative and decision-making data. 
For example, the buyer may obtain lists of suppliers and 
associated data such as prices, terms, and quality and 
delivery ratings. 

As shown in FIG. 9, support data includes sourcing 
data, commodity searching, supplier searching, history 
searching, standard clauses, and on order data. The 
supplemental data is assigned to any open RP at the 
option of the buyer, who uses menus and command lines 
to select data categories and search fields. 

FIG. 10 illustrates a sourcing search window 101, 
obtained by using the sourcing command of menu 91. 
Sourcing data is requested by a buyer who seeks pur- 
chasing information for a particular supplier or item. As 
an example of a sourcing process, a list of suppliers, 
ranked according to certain criteria is provided to the 
buyer. The criteria include characteristics such as qual- 
ity and delivery, and each is given a numerical value, 
from which algorithmic or artificial intelligence tech- 
niques may be used to determine rankings. 

FIG. 11 illustrates a cornmodity search window 111, 
obtained with the commodity search command on 
menu 91. Commodity data includes commodity codes 
and commodity descriptions. Other search windows 
(not shown) may provide various other data categories. 
Supplier data includes identification number, name, and 
address. History data includes past purchasing informa- 
tion on a particular item. Standard clauses are additional 
terms and conditions that the buyer may select to ac- 
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company a purchase order. On order data includes RF's 
and PO's that are currently on order. Each of these data 
categories has a number of data fields, and may be 
searched with respect to a selected field. For example, a 
buyer may search the commodity data using either the S 
code or description as a search field. 

FIGS. 12A and 12B illustrate action menus 121 and 
122 for an opened RP and an RP work list, respectively. 
In addition to viewing work lists, opening documents, 
and obtaining supplemental information, the buyer may 10 
"act" on a document. These actions are the equivalent 
of handling hard copies of a document in a non- 
automated system. As shown, Actions may be selected 
from either an open document window as in FIG. 12A 
or a work list window as in FIG. 12B. Performing an 15 
action from a work list affects all listed documents that 
have been marked by the buyer. Performing an action 
from an open document affects only that document. 

FIG. 13 illustrates a PO work list specification win- 
dow 131. This window permits the buyer to create a PO 20 
work list that includes only PO's that meet selected 
criteria. For example, the buyer may create a work list 
of PO's for the same supplier. 

FIG. 14 illustrates a PO work hst window 141. The 
data in this window is automatically updated as the 25 
buyer receives new PO's and as existing PO's become 
filled orders. Once data is verified by mainframe 11, an 
RP is removed from the RP work Hst 41 and added to 
the PO work list 141. 

FIG. 15 illustrates a PO work list sort menu 151, 30 
which permits the buyer to sort the PO work list 141 
according to various data fields. For example, the work 
list 141 may be sorted by total value of the order. 

FIG. 16 illustrates an opened PO window 161. Like 
opened RP's 61, opened PO's 161 represent data that 35 
would be contained in a hard copy PO of a non- 
automated method. Data fields in the PO may be pro- 
tected or unprotected from input or modification by the 
buyer. 

FIG. 17 illustrates a PO attachments menu 171. Like 40 
the RP attachments menu 71, PO attachments menu 171 
permits the buyer to view, create, and update attach- 
ments that simulate those used in standard non- 
automated procurement systems. The attachments are 
the equivalent of the various physical documents that 45 
would be attached to a PO. 

FIGS. 18A and 18B illustrate action menus 181 and 
182 for PO work lists and opened PO's respectively. In 
a manner similar to actions taken with respect to RF's, 
the actions available from the PO action menu permit 50 
the buyer to select actions that are carried out by work- 
station 20 to simulate the procedures and routing of a 
non-automated system. 

A feature of the invention is that printouts , can be 
easily generated to provide hard copies of procurement 55 
documents and reports. These printouts can be gener- 
ated either on-site for delivery to entities external to the 
system, or at a designated destination so that manual 
delivery is avoided. 

FIG. 19 illustrates the programming architecture of 60 
the software programs of buyer station 11 that manage 
the user interface. The general design of the program- 
ming surrounds application programming 21 with a 
layer of utility programs, which provide application- 
specific and generic services beyond those provided by 65 
OS/2 software. Thus, the application programming 21 
is freed of the tasks of interfacing with the PM services 
of OS/2. 
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In addition to application program 21, the compo- 
nents of the workstation 20 software are: main menu 22, 
screen manager 23, validation functions 24, form edit 
25, and a screen library 26. These utilities are closely 
coupled and in constant communication with each 
other. Each calls upon the others to perform services on 
behalf of application program 21. 

Application program 21 is primarily a collection of 
screens to be presented to the buyer and tasks written 
for each screen. The task registers its window proce- 
dure with PM, calls a function of screen manager 23 to 
create a screen window, and calls another function of 
screen manager 23 to read the screen. Before the screen 
is displayed, non-literal fields are initialized, which may 
include a call to obtain current values from linked fields 
on other active screens. 

Application program 21 dynamically modifies menu 
items entries' to indicate what options are currently 
available to the user. This is accomplished by sending 
messages to main menu 22 when changes in menu 
choices are needed. 

Main menu 22 is a driver program that controls the 
main menu and begins a task when the corresponding 
menu item is selected. When the buyer selects a menu 
item, main menu 22 notifies the application program 21, 
which then acts appropriately. 

Screen manager 23 is a collection of routines that 
simplify screen management with an OS/2 PM menu 
driver interface. Screen manager 23 also controls buyer 
input via a mouse and keyboard Screen manager 23 
permits data fields on multiple screens to be linked so 
that when a field on one screen changes, fields on other 
screens that contain the same data are updated. Screen 
manager 23 has functions that handle window manage- 
ment functions, such as sizing, moving, and scrolling. 

As a buyer runs an application program 21, the buyer 
can enter new data in data fields on the display of work- 
station 11. Screen manager 23 notifies the application 
program 21 of the change. Application program 21 
causes validation of the data by invoking the validation 
functions 24. Validation involves such tasks as deter- 
rnining whether the data type is proper or whether data 
is factually true. An example of the latter is determining 
whether a supplier number is for an existing supplier. 

Form edit 25 is a utility program used for designing 
screens. It maintains a disk file library of all screens, 
with a screen being comprised of a group of field de- 
scriptions. Fields can be of several format types, includ- 
ing text, numeric, list-box, edit-box, push-button, data, 
or zipcode formats. Each field may be given a name, 
which is used by a task to reference that field. Each field 
is located by the row-column position on the display 
screen, and its size is measured in terms of rows and 
columns. Colors are used to differentiate literal, pro- 
tected, or unprotected fields, with literal fields being 
those with static data that is usually never changed. 
Other fields usually have initial values assigned by the 
task. Unprotected fields may be changed by the buyer. 
Fields have various attributes used to select visibility, 
keyboard protect status, numeric edit functions, text 
justification, eta These attributes control how the field 
is displayed by screen manager 23. Field values and 
attributes may be changed and queried by the task using 
functions from screen manager 23. Different versions of 
these functions control different data types. 

During run time operations, the tasks of applications 
program 21 use various messages, which are standard 
for OS/2 and PM After initialization, the task enters a 
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message loop to wait for and then respond to received Referring to FIG. 20, the interactive transfer process 

messages, until it receives a WM— QUIT message. The is used when a buyer is working on a document and 

task specifies a default window procedure, rather than a needs data not found on the local database. In step 200, 

PM equivalent All regular PM messages come to the application program 21 determines that global database 

task's window procedure, and the task gets priority to 5 access is required and calk a server transfer program to 

these, messages. The task may ignore a message, in download the data from mainframe 1L The server 

which case the message is handled by screen manager transfer program is described in further detail below. 

23* The batch process is used in a number of different 

Application task message handling is mostly con- situations. Some examples of batch data transfer are: (1) 
cerned with changes made to input fields and actions 10 when a new document is created or updated by a user 

selected by the buyer. Most messages that are sent to the system, such as requisitioner system 12, (2) when a lo- 

task concern a specific field, which is identified by field cally updated document is validated, or (3) when a local 

name. document is processed such that it is to sent to another 

One field attribute is notify, which a task may use to queue, for example, an RP to PO conversion. The batch 
specify that it wants a notification message about any 15 process is based on triggers, which are database records 
key stroke or any mouse click that happens in that field. that represent a logical set of data that is to be moved 
Such messages identify the input that occurred and the between a local database of buyer system 10 and main- 
field. An example, is a pushbutton field, which can be frame 11. 

related to when a mouse button is pressed and which Thus, as indicated by step 203, server 19 continually 

button. Screen manager 23 converts PM mouse mes- 20 polls mainframe 11 for triggers. In step 204, the triggers 

sages, identified by pixel coordinates where the mouse are downloaded and stored in a local trigger table. Also, 

clicked, to a workstation 11 mouse message which iden- as indicated by step 205, application program 21 may 

tifies the field name. insert triggers locally, such as in the cases of examples 

A task receives a validation message if the buyer (2) and (3) in the preceding paragraph, 
modifies data in a field and attempts to move to another 25 In step 206, a dedicated trigger to-do list process, 
field. The task may then query the current value of the which runs on server 19, schedules each trigger to a 
field, verify it, and refuse to permit the user to leave the request handler that is appropriate for the request de- 
field if the modification is unacceptable. If the buyer pending on the type of data requested and its location 
clicks on a menu or a close command after attempting within mainframe 11. To-do list process is essentially a 
to modify a field, the task intercepts the WM_ CLOSE 30 queue manager. 

and WM—COMMAND messages, and calls a proce- Referring to FIGS. 20 and 21, in both the interactive 
dure that forces an immediate validation message for and the batch data transfer, the server transfer program 
the field transfers data between buyer system 10 and mainframe 
List-box fields are a special case, which require a 11. FIGS. 20 and 21 illustrates various modules and 
series of messages requesting each additional line of 35 functions of this server transfer program, 
data for the box. Initially, and again each time the field In the batch data transfer process, the request handler 
is scrolled, additional data is requested. Only enough calls the server transfer program to initiate a transfer 
data is requested to fill the visible part of the box. These request In the interactive data transfer process, the 
messages are in the form of GetFirst, GetLast, GetNext, request is generated as a part of the application program 
or GetPrevious queries. A line of data is returned to the 40 21 and a queue manager is not necessary. In both pro- 
task to be used as a key to obtain the next line, so that cesses, the request contains information about the direc- 
the task need not be involved with scrolling functions- tion of data flow, Le., whether it is to be uploaded or 
When the buyer selects a list-box line the data on that downloaded, the type of data, and the identity of the 
line is returned to the task for identification of the line. mainframe if the mainframe system 11 has more than 
Such selected lines can be marked visibly for the buyer, 45 one mainframe. 

and are treated two ways as requested by the task — ei- In step 210, the request is sent to a queue handler via 

ther all other lines are unmarked so only one is selected an OS/2 named pipe. In step 211, the queue hg«dlf 

or all other lines are left as is so that several can be inserts the request into an OS/2 IPC queue for schedul- 

selected. ing. 

After an application program 21 receives and vali- 50 In step 212, a request manager reads the request from 
dates input from the buyer, it typically performs numer- the queue. In step 213, a communications interface for- 
ous database calls. These calls use the Structured Query mats the data to an IBM 3270 structured field buffer for 
Language (SQL) interface to retrieve, update, insert, transmission to mainframe 11. The communications 
and delete data columns and rows on the tables in the interface uses 3270 emulation software, 
local database 27. Most of the code and logic of applica- 55 Within the structured field buffer is an IMS transac- 
tions program 21 substantially involve database access tion code, which specifies what type of transfer is to 
to acquire the necessary data fields to populate screen occur and what IMS system the transaction should be 
displays for buyer interaction. executed on. The IMS transaction code, together with 
Global Data Downloading ^ associated structured fields are processed through 
1/uwmuauilJ 6 60 the IMS message format service bypass mode. 

FIGS. 20-22 illustrate the process of providing Referring now to FIG. 22, the mainframe transfer 

•transparent" access by workstation 20 to global data, program receives the request from the server transfer 

which is stored on mainframe system 1L Two types of program in the form of the structured field buffer. FIG. 

access are provided: interactive and batch. FIGS. 20 22 illustrates various modules and functions of this 

and 21 illustrate the transfer of data within buyer system 65 mainframe transfer program. 

20 for interactive and batch access, respectively. FIG. In the case of downloads, in step 214, a download 

22 illustrates the transfer of data between mainframe 11 manager receives the request and passes it to a request- 

and buyer system 10 for both types of access.' unique DB I/O module, depending on the type of data 
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requested and where it resides on the mainframe data- 
bases. This request-uniqueness is similar to the unique- 
ness in the request handlers of the generic transfer sys- 
tem. 

In step 215, the D8 I/O module obtains the requested 5 
data. For each row of data, the DB I/O module pro- 
vides a descriptor table, which itemizes the types and 
sizes of each data column. Although this description 
assumes the source data is in a DB2 table, this is not 
necessary to the invention- The primary characteristic 10 
of the source data is that it may be described as data 
types appropriate for the particular database. 

In step 216, the mainframe transfer program trans- 
lates the outbound data from EBCDIC to ASCII. Each 
DB2 row is translated to a corresponding OS/2 DBM 15 
format row. The result is one or more structured field 
messages containing the requested data. This message is 
referred to herein as the "mainframe response". In step 
217, the mainframe response is transmitted to buyer 
system 10. 20 

Referring again to FIGS. 20 and 21, in step 218, the 
request manager receives the mainframe response from 
the mainframe transfer program. The request manager 
examines flags in the response header to determine if the 
download is finished or in-progress. The download is 
treated as being in-progress if the request represents 
more data than can be transmitted in a single IMS trans- 
action. In that situation, the data is buffered and the 
IMS transaction is re-scheduled. ^ 

In step 219, the server transfer program returns each 
data record to the request handler via another OS/2 
named pipe. The data is then inserted into the local 
database in the case of batch data transfers or passed to 
application program 21 in the case of interactive data 35 
transfers. Also, the appropriate worklist is notified, 
using a notification message, to display the new data. 

Data Uploading 

In data uploading, the source of the data is buyer ^ 
system 10 instead of mainframe 11 and the destination 
for the data is mainframe 11 instead of buyer system 10. 
Uploading is initiated by a workstation 20 when a work- 
station application has changed data, and as a result the 
data must be validated or updated on a data base of a 45 
mainframe. 

In the first step, application program 21 places an 
upload request into a workstation queue. The data items 
in the queue are flagged to prevent further user changes 
to that data until the upload is complete. The remaining 50 
steps of the data uploading process are the reverse of 
those described above for the downloading process. 
The upload process of the mainframe transfer program 
is similar to the download procedure, except that an 
upload manager replaces the download manager. Main- 55 
frame 11 returns an acknowledgement instead of down- 
loaded data. 

Other Embodiments 

Although the invention has been described, with ref- 60 
erence to specific embodiments, this description is not 
meant to be construed in a limiting sense. Various modi- 
fications of the disclosed embodiments, as well as alter-; 
native embodiments will be apparent to persons skilled 
in the art. It is, therefore, contemplated that the ap- 65 
pended claims, will cover all modifications that fall 
within the true, scope of the invention. 

What is claimed is: 
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1. A method performed by a computer system imple- 
menting an automated procurement system including a 
mainframe computer, a global database, a local database 
and a server computer, comprising the computer per- 
formed steps of: 

storing global data in said global database of said 
mainframe computer, said . mainframe computer 
being programmed with mainframe transfer soft- 
ware; 

storing local data in said local database of said server 
computer, said server computer being programmed 
with server transfer software so that said server 
computer is in communication with said mainframe 
computer; 

controlling by said server computer a workstation for 
interactive input and output with a buyer, said 
workstation being programmed with a buyer inter- 
face, and said workstation being in communication 
with said server computer; 

accessing said buyer interface to permit said buyer to 
process procurement documents; 

determining by said server computer whether process 
data corresponding to said process of said procure- 
ment documents is located in said global data in 
said global database or in said local data in said 
local database; 

controlling by said computer system a manager sys- 
tem to approve said procurement documents after 
said procurement documents are processed; and 

providing, by said mainframe transfer software and 
said server transfer software, said process data to 
said buyer so that a location of said process data is 
determined without interaction of said buyer; and 

wherein the method further comprises the step of 
supplying said global data from said global data- 
base for use by said buyer for decision-making; and 

wherein said global data includes supplier rankings 
including criteria data to rank each supplier with 
respect to other suppliers, and the method further 
comprises the steps of determining by the com- 
puter system said supplier rankings, displaying said 
supplier rankings on said workstation, and receiv- 
ing input from said buyer responsive to said sup- 
plier rankings. 

2. A method performed by a computer system for 
automated procurement, using an interactive worksta- 
tion having a local database and a buyer interface, in 
communication with a mainframe having a global data- 
base, comprising the computer performed steps of: 

displaying a plurality of documents used for procure- 
ment on said workstation, said documents includ- 
ing queries for data to be supplied by a buyer; 

selecting a document on said workstation from said 
documents; 

determining by said workstation whether support 
data is needed for processing said selected docu- 
ment and supporting said selected document is 
located in said global database; 

retrieving by said workstation said support data from 
said global database if needed to support said se- 
lected document in accordance with said determin- 
ing step; 

displaying said support data on said interactive work- 
station if needed to support said selected document 
in accordance with said determining step; 

ranking by said computer system suppliers to rank 
each supplier with respect to other suppliers in 
response to a request for said support data; 
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receiving input data from said buyer in response to 
displaying said support data for processing said 
document, by using said buyer interface; and 

updating and maintaining said support data so that 
said support data in said local database is the same 
as said support data in said global database by said 
computer system. 

3. The method of claim 2, wherein said method fur- 
ther comprises the step of routing said document to 
appropriate users of other computer systems, said other 
computer systems being in communication with said 
mainframe. 

4. The method of claim 2, wherein said method fur- 
ther comprises the step of using said workstation to 
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inform said buyer of a worklist of documents requiring 
processing. 

5. The method of claim 4, wherein said worklists 
include a line of data representing a single document 
and the method further comprises the step of selecting 
an additional document from said worklist to be initial- 
ized for display of additional data. 

6. The method of claim 4, wherein said method fur- 
ther comprises the step of sorting said worklist accord- 
ing to a data field selected by said buyer. 

7. The method of claim 2, wherein said method fur- 
ther comprises the step of selecting and processing at- 
tachments to said selected document by said buyer. 

8. The method of claim 2, wherein the method further 
comprises the step of determining said support data 
needed for processing, by using said buyer interface. 
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